Data communications in packet switched (PS) networks includes the transmission of data over a network as a sequence of small data chunks or suitable sized data blocks called packets. Each packet is passed through the network from a source (e.g. a user equipment or other network entity) to a destination (e.g. another user equipment or another network entity) via one or more network entities or nodes. Each packet typically includes a data payload, which is a small chunk of the data being transmitted, and a packet header, which typically provides information such as the destination and/or source address and the type of packet or communications protocols being used. PS networks may comprise or represent a communication network that groups all transmitted data into suitable sized data blocks called packets. Examples of specific PS networks that may be used in certain embodiments of the described network include, but are not limited to, legacy PS networks such as the second generation (2G), 2.5 generation (2.5G), third generation (3G), and fourth generation and beyond (4G and beyond) type networks, and/or evolved packet switched (EPS) networks, and/or all internet protocol (IP) based PS networks.
For example, the so-called Universal Mobile Telephone System (UMTS) (a legacy PS network commonly known as a 3G radio communication system), which has evolved into using enhanced PS network technologies such as High Speed Packet Access (HSPA) technology. In addition, air interface technologies within the UMTS framework have begun to evolve towards new air interface technologies defined in the so-called Long Term Evolution (LTE) and LTE-Advanced systems.
The next generation radio communication systems and networks such as LTE and LTE-Advanced are considered to be all IP networks. These networks will have an upgraded PS network infrastructure called the evolved packet system (EPS). The EPS includes an evolved packet core (EPC) that forms the basis of the core PS network for the all IP network. These enhanced PS networks will provide all the mobile core functionality that, in the previous generations (2G, 2.5G, and 3G), has been realised through the existing CS networks and legacy PS networks.
The user equipment (UE) may comprise or represent any device used for communications. Examples of user equipment that may be used in certain embodiments of the described network are wireless devices such as mobile phones, terminals, smart phones, portable computing devices such as lap tops, handheld devices, tablets, netbooks, computers, personal digital assistants and other wireless communication devices, or wired communication devices such as telephones, computing devices such as desktop computers, set-top boxes, and other fixed communication devices.
A network element or entity may comprise or represent any network node, device, function, or entity for use in a telecommunications network which can be managed over a specific interface. Examples of network elements or entities that may be used in certain embodiments of the described network(s) are network elements, nodes, devices, functions, or entities that make up core network(s), access network(s) such as packet or circuit switched network(s), IP based networks, 2G, 3G, 4G and next generation networks, IMS core network, IMS service network, and service and external networks and the like.
Data communications has evolved to use many different communications protocols or standards (e.g. Internet Protocols, TCP/IP protocols, UDP protocols etc.) for use in transmitting data from a source to the destination. These communications protocols may be layered in a so-called protocol stack in which a layer of the protocol stack serves the layer above it and the layer below it.
Typically a protocol stack includes an application layer, a transport layer and a network layer. The application layer includes logic needed to support various user applications or application programs, the transport layer includes mechanisms to provide reliable communication of application data controlled by the application layer, and the network layer is concerned with exchange of data between the source and the destination or the physical devices in the network. Examples of protocol stacks include the TCP/IP protocol suite (providing application, transport, internet, network access, and physical layers) or the open systems interconnection (OSI) model (providing application, presentation, session, transport, network, data link, and physical layers).
FIG. 1a illustrates the structure of an example packet with IP and transport protocol headers in the packet header followed by the packet payload, which includes higher layer protocol information and the data or data chunk being transmitted. In order to provide reliable communications, data is passed between the layers in the form of packets, in which at each layer may insert additional data related to that layer to the payload of a packet and a header related to that layer. This means that packets may include one or more packet headers associated with the various communications protocols and/or layers of the protocol stack that may be used when communicating the data from the source to the destination. The headers depend on where in the network or at what level/layer (e.g. application layer, transport layer, or network layer) of the communication protocol or system the packet data is situated.
Since most of the packet header information is either static or are updated according to predictable patterns, the packet headers can be compressed to increase transmission efficiency. Conventionally, packet headers in packet traffic transmitted over a network are compressed by analysing the header(s) of each packet to determine the number of bits that are to be compressed. For example, when applying packet header compression, the packet header is analyzed in detail, and specific packet header fields are divided into static, semi-dynamic and dynamic fields. In this case the packet header shall be treated as a bit stream without making specific considerations about the header, except for limiting the compression range to cover the bits of the header.
FIGS. 1b-1d illustrates various protocol header formats that may be used. FIG. 1b illustrates the protocol header format for the User Datagram Protocol (UDP) protocol, FIG. 1c illustrates an Internet Protocol version 4 (IPv4) header format for the IPv4 protocol, FIG. 1d illustrates an Internet Protocol version 6 (IPv6) header format for the IPv6 protocol, and FIG. 1e illustrates a Transmission Control Protocol (TCP) header format for TCP. The sizes of the headers for the different IP level protocols are shown in Table 1.
TABLE 1Example IP level protocol headers and sizes.Protocol header (size) [bytes]Optional fields, size [bytes]IPv4 (20)Options (20-60)IPv6 (40)Extension headersUDP (8)TCP (20)Options (0-40)
It is apparent that each protocol uses a different header format that has a different size. In the header, the IP version is visible in the “version” field in the IP header, and the underlying transport protocol is also given in the IP header. IP packet inspection (PI) is normally sufficient to identify which protocols are being used over a specific connection.
Packet Inspection may comprise or represent the analysis of packets at different levels, from IP header classification to the deep packet inspection (DPI). The following describes some of the different levels of packet inspection and analysis that may be performed; these include, but are not limited to, IP header classification, shallow inspection, DPI, and heuristic detection.
IP header classification (a.k.a. 5-tuple inspection) is used to inspect packets up to the Internet layer, the so-called 5-tuple (Source IP address, Source IP port, Destination IP address, Destination IP port, Protocol (which runs on Transport layer, e.g. TCP, User Datagram Protocol (UDP), etc.) IP header classification is useful for identifying traffic targeting a specific port number, or a specific protocol. It is also useful when traffic from certain traffic domains, e.g. the Internet or Virtual Private Networks (VPNs), shall be treated in a specific way. For example, giving all Internet traffic a certain quality of service treatment (e.g., priority) or adding a different security protocol to a VPN.
Shallow inspection (a.k.a. Stateful inspection) is an analysis of the Transport Level protocol state, by inspecting the current protocol header (TCP, UDP etc.). For example, analysing the sequence of TCP header flags like SYN, ACK and FIN tells the state of the connection, and the receiver window size. Shallow inspection is useful when link layer algorithms are triggered by sequences of events of higher layer protocol interactions, without the need of knowing what content is carried. One example of use is to decrease the user terminal battery consumption by letting lower layer protocol states follow higher layer protocol layers. Shallow inspection also includes the analysis of all the fields of the IP header.
Deep packet inspection (DPI) is an analysis of data content on the Application Layer, e.g. hypertext transfer protocol (HTTP) state, video frame content etc. One common example where DPI is used is caching, where the HTTP request is analysed to identify which content to fetch from the cache. Link layer algorithms can also be made to adapt to specific types of content or applications.
Heuristic detection includes pattern detection or statistical identification methods on Application Layer data. Typically needed for classification of services with encrypted content, or for applications that intentionally tries to avoid identification (e.g., to avoid blocked of free voice of IP applications).
Conventionally, due to the large variation of possible packet headers in packet traffic transmitted over a network, PI needs to be performed on each packet when applying packet header compression, as the packet header is analyzed in detail, and specific packet header fields are divided into static, semi-dynamic and dynamic fields. PI may be used to determine the length of the packet header such that the header may be compressed using packet compression algorithms prior to transmission. The header length may represent the number of bits or bytes of the packet header, which may include one or more headers from the different communications protocols used in transmitting the packet.
For example, a file compression method, or compression methods working on bit streams, like GZIP or similar (which is LZ77 lossless compression combined with Huffman entropy coding), may be applied on specific parts of a bit stream, e.g. the packet headers only. Alternatively, a network operator or session or application may apply compression to IP packet headers only, that is, it is desired to compress the headers without further parsing of the IP packets. This means PI may need to be performed on each packet to determine the number of bits in the packet header that are to be compressed.
Given the sheer number of packets being transmitted in a network, performing PI such as IP header classification, shallow inspection, DPI, and/or heuristic detection for each packet in order to determine the header length of the header to be compressed is becoming infeasible. This is due to the large amount of packet traffic, the computational resources required for PI on each packet due to insufficient hardware or software (e.g. UEs), and/or the delays incurred for performing PI on each packet. Therefore, there is a significant need to optimise the compression and decompression of packet headers for packet traffic in the network while minimising the computational resources and delays in transmitting packets in the network.
Whilst performing packet inspection (PI) on each and every packet in the network may determine the header length of each packet, it is rather computationally intensive and can incur significant delay.